The standard Gateway selection process in 3GPP networks is described in 3GPP technical specification [3GPP TS 29.303 V8.2.0 (2009-06), Domain Name System Procedures; Stage 3 (Release 8)].
A bearer for a PDN connection spans a number of user plane nodes from the User Equipment (UE), via the eNodeB (eNB), the Security Gateway (SeGW) at the border of the operator network, the Serving Gateway (SGW) to the PDN Gateway (PGW). In many cases the path of the traffic over the PDN connection continues from the PGW to an Autonomous System Border Router (ASBR), i.e. one of the operator's border routers constituting a peering point with other carriers, and further into the Internet. The Mobility Management Entity (MME) is a pure control plane node which, among other tasks, is involved in PDN connection establishments.
When a PDN connection is established, or its path is altered, some or all of the traversed nodes need to be (re)selected. Different selection mechanisms are used for different nodes:                The eNB is selected by the User Equipment (UE), governed by radio conditions and guiding parameters in the system information broadcast in the cells. (An exception is inter-eNB handover, where the source eNB, aided by measurement data from the UE, selects the target cell, and thus target eNB, for the handover.)        The SeGW selection is simply a consequence of the eNB selection, since the SeGW that the eNB is connected to has to be used.        The SGW is selected by the MME.                    The SGW is selected for the default bearer at network Attach. A UE can only have a single SGW allocated at a time, so the same SGW is used also for subsequent bearers, irrespective of Access Point Name (APN).            The allocated SGW can be changed due to mobility, e.g. at handover or Tracking Area Update (TAU), in order to optimize the route or because the old SGW does not serve the new eNB. A SGW may serve a limited part of the PLMN's area (i.e. a limited fraction of the eNBs in the PLMN), denoted SGW Service Area (SA). SGW relocation due to fault situations is also possible.                        The PGW is selected by the MME.                    The PGW is selected for the default bearer for a certain APN. A UE can only have a single PGW allocated at a time for a certain APN, so the same PGW is used also for subsequent bearers for the same APN.            A PGW is allocated to the UE for each APN the UE chooses to use for communication (i.e. to establish a bearer for). Hence, a UE can be allocated multiple PGWs, one for each APN.            An allocated PGW is not changed—it remains the same irrespective of mobility for as long as the UE remains attached to the network (for each APN). Hence, each PGW must serve the entire PLMN.                        The ASBR is selected through routing information and policies in the transport network layer and may hence in essence be seen as a consequence of the PGW selection. An exception is a roaming scenario where the operators of the visited and home PLMNs have established a mutual peering arrangement using a dedicated ASBR. In this scenario the ASBR is essentially a consequence of the PLMNs involved. If the two PLMNs have multiple dedicated ASBRs for mutual peering, then the choice among these ASBRs may be a consequence of the PGW selection. SGW/PGW selection takes place in the network whenever a SGW and/or a PGW needs to be allocated to a UE, either to serve a new PDN connection or to replace a previously allocated SGW. There are three cases in which SGW/PGW selection is triggered:        Attach (which includes establishment of an initial PDN connection and default bearer towards an APN). In this selection case both SGW and PGW are selected.        SGW relocation. In this selection case only the SGW is selected, while the PGW(s) remain(s) fixed.        Additional PDN connection establishment. In this selection case only a PGW is selected, while the already allocated SGW is reused.        
According to present applicable 3GPP specification [3GPP TS 29.303 V8.2.0 (2009-06), Domain Name System Procedures; Stage 3 (Release 8); and 3GPP TS 23.003 v9.0.0, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 9)”, September 2009] the mechanisms that the MME can leverage to enable appropriate selections of SGWs/PGWs are based on the Straightforward Name Authority Pointer (S-NAPTR) DNS application (specified in [L. Daigle & A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)”, RFC 3958, January 2005]). S-NAPTR uses NAPTR and SRV resource records (RRs), but with certain restrictions in the flexibility of what is allowed in the NAPTR RRs. The following (Table 1) is a generic description of a NAPTR RR obeying the S-NAPTR restrictions:
TABLE 1An example NAPTR Resource Record with the restrictions stipulated byS-NAPTR. The flags are restricted to the “a”, “s” or “” (no flag) flags and theregexp field is unused (i.e. it is empty). The values of the order and pref fields aremerely examples.S-NAPTR Resource Record DataCommentexample.comFQDN to matchtheFQDN in thequery.Data describedRR classRRin the comment(Internet)typeOrderPrefFlagscolumnINNAPTR10010“a”/“s”/“”Example-Service:protocolservice:example-protocol“”Regexpreplacement-Replacementexample.com
In this context S-NAPTR is utilized to indicate SGWs/PGWs which match the present selection case, e.g. in terms of supported APN, supported mobility protocol, support of the current location (Tracking Area) and/or topological closeness. This information is stored in NAPTR resource records (RRs) in the DNS server(s):                TAI→SGW mapping: The TAI is encoded in the field matching the FQDN in the query in the form of two labels for the TAC (one for the low byte, tac-lb<TAC low byte>, and one for the high byte, tac-hb<TAC high byte>) to the left of the label “tac” in an FQDN ending with epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (which thus includes the PLMN ID which complements the TAC into a TAI). An example could be tac-lb231.tac-hb14.tac.epc.mnc2.mcc46.3gppnetwork.org. Note that an FQDN is built up by multiple labels separated by dots (e.g. foo.example.com). The “< >” characters are often used to indicate a generic FQDN or label format, in which the expression within the brackets is supposed to be replaced by some real value/expression in order to form a specific (usable) FQDN/label. Using this notation, a generic expression for a three-label FQDN could be <label1>.<label2>.<top-domain-label>.        Supported mobility protocol→SGW/PGW mapping: The supported mobility protocol may be encoded in the service field.        Supported APN→PGW mapping: The APN is encoded in the field matching the FQDN in the query in the form of multiple labels, the rightmost of which should be “apn”, in an FQDN ending with epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (e.g. internet.apn . . . epc.mnc2.mcc46.3gppnetwork.org or, generically, <apn-label-1>.[ . . . <apn-label-n>] . . . epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org).        Topological closeness: The topological information may be encoded in the FQDNs in the replacement field in the form of multiple labels constituting the “node name”. By comparing the node names of two different GWs (typically a SGW and a PGW) the MME may infer the relative topological closeness of the nodes from the number of consecutive identical labels (starting with the rightmost node name label)—the more identical labels, the closer the two nodes. Appending the label “topon” as the leftmost label indicates that topologically significant information has been encoded in the node name labels. A node name is canonical in the sense that it should be the same for all interfaces of a node (in case the node is multi-homed). Multiple (non-equivalent) interfaces of the same node, allocated for different services or connected to different networks, are distinguished by the first label to the left of the node name.        
To let all of the above information impact the SGW/PGW selection, multiple NAPTR RRs have to be retrieved, corresponding to multiple DNS queries. However, the DNS mechanisms contain optimizations that drastically reduce the number of DNS queries required in practice. DNS servers send “additional section” information in their replies, which attempt to foresee and preclude subsequent requests, and in addition, DNS clients cache received DNS replies (although no longer than the lifetime indicated in the reply), which eliminates the majority of the queries.
Nevertheless, even though most of the DNS queries are avoided, a series of FQDNs (corresponding to potential queries) are involved in the procedure from the FQDN in the initial query to the FQDN in the finally returned A/AAAA resource record. The structure of the initial (input) FQDN and final (output) are specified by 3GPP, but the (arbitrary number of) intermediate FQDNs are left entirely to each operator to use in any way they assess beneficial, e.g. to encode other SGW/PGW properties which may be useful in the SGW/PGW selection process.